Implementing Vulnerability Scanning in a Large Organisation

This paper describes how the security group in our organisation uses Vulnerability Scanning to demonstrably improve our security posture. This covers the reasons and requirements for scanning, how this fits with our current business structure and how we used a web interface to distribute the collected data to our system custodians. Also covered are our techniques for dealing with false-positives, an explanation of the chosen solution and how the system was tailored to operate from an enduser perspective. Finally, we discuss the impact that the system has had on our organisation. © S A N S In st itu te 2 00 3, A ut ho r r et ai ns fu ll ri gh ts . Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2003, As part of GIAC practical repository. Author retains full rights. Introduction Vulnerability scanning in itself is now very much a “point and click” affair. Scans are available freely on the web [1] and the majority of tools are provided with a graphical interface. However, implementing vulnerability scanning within a large organisation is about much more that installing the software and running it. This paper describes how our security group now uses vulnerability scanning to demonstrably improve the security posture of our organisation. The need for Vulnerability Scanning We are a large academic institution where large chunks of our internal network can be considered “untrusted” – as we allow students to use their own laptops in the library and within halls of residence. Some departments are now also operating wireless network access for their researchers. We also offer VPN and dial-up services to our users from their homes. In addition, we offer internet access to academic visitors and to those using our conference facilities. Even without these other attack vectors, perimeter security is not enough. An academic firewall must support the very varied activities of our researchers – video conferencing, GRID programmes [2] and collaborative research all require firewall exceptions. Hence, we must apply the principle of Defence in Depth and protect our host systems. Scanning in itself is not a policy enforcement tool, but it does provide us with the necessary information to ensure that we can keep our hosts safe from known attacks. Other security problems, like weak passwords or poorly coded web sites are a matter for different tools – we do not attempt to address them using this system. In a world of metrics and performance reports, vulnerability scanning is also a useful way of tracking our internal security posture over time. We can use “percentage of vulnerable systems” type statistics to compare departments, demonstrate need for budget / staff and show management that the security group is achieving its mandate. The lack of any internal security data meant we had no way of knowing the risks we faced from internal attack. This is a problem faced by many companies – as illustrated by Paul Simmons of ICI; “Our biggest problem is knowing what we do not know.” [3] As stated by CERT-CC in their best practices, a system administrator is required to do the following: "Whenever an update is released, you need to evaluate it, determine if it is applicable to your organization's computers, and, if so, install it." [4] We do not wish to rely solely on inexperienced administrators making this kind of decision which could affect the entire organisation. Vulnerability scanning provides a way of double-checking the decisions of our administrators. © S A N S In st itu te 2 00 3, A ut ho r r et ai ns fu ll ri gh ts . Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2003, As part of GIAC practical repository. Author retains full rights. By scanning IP ranges, rather than known hosts, the scanning engine also provides an asset discovery mechanism. This is a key part of managing risk, as this will identify the risk for every system, not just the ones we know about. Leveraging the existing business structure As part of our organisational security policy, we already had in place a tiered structure of personnel who had been made responsible for the security of their systems, known as “custodians”. The custodians are, in the main, of basic technical competency. They report to departmental security liaisons who are in themselves responsible for annual departmental risk assessments. There are also our central support teams, from first to third line. These teams interact with the users and custodians on a regular basis. Vulnerability scanning some 10,000 hosts on a regular basis generates a lot of data. No central resource has the time or personnel to sift this information and then distribute it out to each custodian. To utilise this valuable resource, we needed a way of supplying vulnerability scan data to the custodians in a simple and cross-platform fashion. Only by demonstrating that the data collected can be of real benefit will our user community accept the concept of vulnerability scanning. Defence in Depth and Risk Assessments As mentioned above, vulnerability scanning itself is an important part of any Defence in Depth strategy. Our network perimeter is policed by firewalls and IDS systems and key internal groups are protected by internal firewall solutions. The next step in this chain is host security. Identifying vulnerable hosts through scanning is an obvious benefit when attempting to secure them. So how does vulnerability scanning fit with the SANS four step plan [5] to risk management? Step 1: Identify Risks A vulnerability report is an excellent way of identifying the risks and attack vectors open on each host. Step 2: Communicate your findings This is the critical step: we must be able to pass the information down to the people who can actually effect changes – i.e. our custodians. Step 3: Update (create) policy as needed Policy already exists granting our group permission to vulnerability scan systems where the users have been properly notified beforehand. The policy covering the requirements of each custodian (their “job description”) may need updating in response to data collected – e.g. we may have to change the frequency with which the custodian checks the machine if it turns out that patches are being released faster than they are being applied. © S A N S In st itu te 2 00 3, A ut ho r r et ai ns fu ll ri gh ts . Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2003, As part of GIAC practical repository. Author retains full rights. Step 4: Develop metrics to measure compliance Using vulnerability scanning, it is easy to tell whether the custodian is doing their job properly. By scanning regularly, the overall security posture of the organisation can be measured. We can also look for successful custodians and use their experience to train others. Getting Started We can now summarise the requirements for our organisation Requirements 1. A vulnerability scanning engine capable of scanning multiple OS platforms (our organisation uses a mix of Windows, Linux, Unix, MacOS, etc.) 2. A low cost solution 3. Ability to disseminate data to the authorised parties 4. Ability to secure data from unauthorised parties (who may be authenticated) 5. Ability to track data over time 6. Ability to generate reports 7. Tie in to our existing databases – e.g. computer registration database Table 1 Requirements Vulnerability scanners are very expensive – with the notable exception of Nessus. As many parties consider Nessus to be amongst the best of the vulnerability scanners [6], and fits very well with the “low cost” requirement, it is the obvious choice. The storage, distribution and reporting of data requirements immediately suggests “database”. We have a large Windows infrastructure within our organisation – hence it was decided to use MS-SQL to backend the data collected during the scans. MySQL may seem a more logical choice (as Nessus connects directly to MySQL), but the Microsoft solution was chosen for two main reasons: 1) We already have existing MS-SQL database servers suitable for our use; these are regularly backed up and maintained by our database team. 2) Our experience with MySQL is limited. We needed to make sure that security on this database was absolute – the data contained within it is practically the keys to the kingdom. MS-SQL also offers data transformation services (DTS), which makes integration with existing data sources much easier. © S A N S In st itu te 2 00 3, A ut ho r r et ai ns fu ll ri gh ts . Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2003, As part of GIAC practical repository. Author retains full rights. Setting up the scanner Using the excellent documentation at the Nessus site [7], the daemon portion of Nessus was setup on a dual processor Linux server. NessusWX [8] was installed on a Windows server running MS-SQL. NessusWX is used to initiate scans by department. We defined groups of subnets to cover each organisational unit so that the scans can be broken down easily. Hence, if we are asked to manually rescan a unit, we are not forced to cover the whole department again. A database was created to hold the Nessus data. NessusWX can be used to generate SQL scripts containing all the data collected during a scan. Running these scripts in the Microsoft SQL Query Analyser imports all the data into the database where it is ready for distribution. Both the Windows and Linux boxes are hardened using the tips provided in the SANS material which includes Centre for Internet Security (CIS) [9] guidelines for each OS. In addition, the Windows machine runs BlackICE PC Protection by ISS [10]. The Linux machine runs IPTables as its host firewall. Integration with existing da ta sources Our computer registration database holds the IP, MAC address and location of each computer we have registered on our network. More importantly for this case, it also holds the registered owner and registered c stodian for those systems. DTS is used to pull this data on a regular basis, so that the user and custodian fields are kept in sync between the two databases.